This invention relates to the field of logic simulation of electronic circuits. More particularly, this invention relates to methods and apparatus for synchronizing independently executing test lists at selected synchronization points during a logic simulation.
Gordon Moore, the cofounder of Intel Corporation, made an observation and prediction that semiconductor performance would double every 18 months, with the price of the new product remaining constant with the old. This observation is now referred to as Moore""s Law, and has remained relatively accurate since the early 1970s. Moore""s Law illustrates the rapid advancement that has and is taking place in the electronics industry. Because of this rapid advancement, the market window for many electronic products is relatively short, with faster and more powerful devices being continuously introduced. Accordingly, there is great pressure to reduce the development time for many products. To significantly reduce the development time for most electronic devices, the design time must be reduced, as the design process typically consumes a majority of the development cycle.
FIG. 1 shows a typical prior art design process for an ASIC (Application Specific Integrated Circuit) device. ASIC devices are commonly used to implement large and/or high performance circuit designs. In a first step, a hardware architect typically determines the requirements for the circuit design and formulates an underlying framework of the function and projected performance characteristics of the circuit design. The architect documents these ideas in a functional specification, as shown at step 12.
The design is then partitioned into a number of blocks and given to one or more logic designers for implementation. The logic designers create a detailed logic design using the functional specification as a guide. Rather than creating schematics, many logic designers express their design in a behavioral language such as VHDL (VHSIC Hardware Description Language), as shown at step 14. Many logic simulation tools can directly accept behavioral language descriptions as input. This not only improves efficiency in developing complex circuit designs, but also allows various sections of the circuit design to be functionally verified before the entire design is complete.
Next, and as shown at step 16, the design is typically logically simulated to verify the functionality thereof. To logically simulate the design, the circuit designer typically provides one or more test input files. The test input files may include a number of test conditions expressed as test vectors or the like. Each of the test vectors may include a value for selected inputs of the circuit design along with an expected circuit response. The logic simulator reads the test input files, simulates the behavior of the circuit design using the test input, and provides a simulated circuit response. The simulated circuit response is then compared to the expected circuit response to determine if the circuit design provides the expected behavior.
After logic simulation is complete, the design is typically passed to one or more physical designers, as shown at step 18. The physical designers place the various cells that represent the basic logic building blocks of the circuit design, and interconnect the cells using a routing tool. Timing information may be extracted and analyzed by both the physical and logical designers. Some timing problems can be fixed by the physical designer by adjusting the drive strengths of various components or placing cells in a different arrangement relative to each other. As shown at step 22, other timing problems can only be resolved by modifying the logic itself. If a problem is resolved by modifying the logic, the modified design must typically be re-verified by re-executing logic simulation step 16 and then the physical design step 18.
After all the logical and physical changes are made, and the design meets the stated requirements, the design is released for fabrication, as shown at step 24. Fabrication can take several months for a typical ASIC device. Once completed, the device is returned and tested, as shown at step 26. If the device does not meet the stated requirements, a design modification may be required as shown at step 22, forcing another design iteration of the logic simulation step 16, the physical design step 18, and the fabrication step 24. Once the device meets all of the stated requirements, the device is released, as shown at step 30.
In most design processes, it is important to reduce the number of design iterations required during the development cycle. One way of reducing the number of design iterations is to increase the fault coverage of the test input files used during the logic simulations. Increasing the fault coverage can increase the probability that all design errors will be detected before the design is fabricated. However, increasing the fault coverage increases the time required to generate and simulate the increased number of test cases. Thus, there is often a trade-off between an increased fault coverage and the design cycle time.
FIG. 2 illustrates a prior art logic simulation process. At step 42, the architect and test designer discuss the logic implementation and define a series of test cases that address the various functional sections and possible interactions of the design. In many designs, such as a MSU (Main Storage Unit) design with multiple parallel ports and crossbar switches (see below), there are many possible functional operations and interactions that could and should be tested. Thus, a large number of test cases are often required to achieve a high level of fault coverage.
For some of the test cases, the test designer can easily define the relevant test parameters. For other test cases, however, such as those that test the parallel nature of the operating hardware, the test designer must use a certain level of parallel thinking. These tests can be more difficult to define. For example, in a test case that simulates the interaction of two parallel operating ports of a MSU module of a large scale symmetrical multiprocessor system, the operation of one port may have to be choreographed with the operation of another port to achieve a desired result. Defining such test cases can require a significant amount of parallel thinking, and can be relatively difficult and time consuming to define.
Once the test cases are defined, the test designer often codes the test cases into a format that can be used to produce an input for the logic simulator. This format may include, for example, a force command, followed by a run command, followed by a force command, etc. Test cases written in this format typically must be interpreted by the logic simulator, and more particularly, a simulation control program of the Logic Simulator. The simulation kernel must usually be interrupted before the simulation control program can process a subsequent line in the coded test case. Because the simulation kernel must be interrupted, the speed of the logic simulation can be significantly reduced.
To increase the speed of the logic simulation, a test driver may be used. A test driver is typically expressed using a behavioral language description and simulated along with the circuit design. Because the test driver can actually be simulated along with the circuit design, the test driver can stimulate the inputs of the circuit design without having to be interpreted by a simulation control program, and thus without having to interrupt the simulation kernel.
Prior to simulation, test data can be loaded into a memory structure incorporated into the test driver. The test data is used to control the inputs of the circuit design during subsequent logic simulation. For example, test data may be loaded into a RAM structure within the test driver, and during logic simulation, the address to the RAM structure may be incremented to provide each of the test vectors to the inputs of the circuit design.
To generate the test data, a test designer may code the desired test cases into a standard programming language like xe2x80x9cCxe2x80x9d, as shown at step 44. When executed, the xe2x80x9cCxe2x80x9d programs may generate a series of data files that can be loaded into memory structures within the test driver, as shown at step 46. The xe2x80x9cCxe2x80x9d programs may also generate corresponding initialization files that can be loaded into the device under test (e.g. MSU RAMs). During simulation, a series of load commands may then be executed by the simulation control program. These load commands load the data and initialization files into the array structures that represent the simulation models of the appropriate memory structures (e.g. RAMs). Clocks are then issued (simulation starts), and the test is performed as shown at 48.
During or at the end of the logic simulation, the results are checked to see if the test passed or failed, as shown at step 50. If the test failed, the results are analyzed to determine whether there was a test problem or an actual logic design problem, as shown at step 52. If a test problem is detected, the test is modified and re-executed as shown at step 56. If a logic problem exists, the logic design must be modified, as shown at step 54, and the logic simulations are re-executed to validate the change. When all of the defined test cases pass, as shown at step 58, the logic simulation process is complete.
To verify many of today""s systems, and in particular large scale symmetrical multiprocessor systems, parallel execution of a number of independently executing test lists is often desirable. For example, it may be desirable to independently control each port of a multi-port MSU module with a different test list. This may allow each port to operate in a non-deterministic manner relative to the other ports, and may allow the detection of design errors that can only be detected by simulating the often conflicting requests provided by the various ports of the MSU.
When using multiple independently executing test lists, it is sometimes desirable to maintain certain timing relationships therebetween in order to accomplish a desired result. For example, it may be desirable to have a first port write a data value to the MSU, and then have one or more other ports request access to the data value that was written. To accomplish this, the first port must write the data value to the MSU before the other ports request access to the data value. If each of the ports were allowed to operate totally asynchronously relative to one another, this may or may not occur. Thus, it is often desirable to synchronizing the execution of the independently executing test lists at selected synchronization points.
One technique for effectively synchronizing the execution of the independently executing test lists at selected synchronization points is to insert large delays into selected test lists. For example, to have the first port write a data value to the MSU before the other ports request access to the data value, a large delay may be inserted into the test lists of the requesting ports to delay when each port requests access to the data value. A limitation of this approach is that the length of the delay is often difficult to calculate or determine. Thus, if erroneous results arc obtained, a designer cannot be certain if the error uncovered a real design error, or if the error occurred because a delay time was under-estimated. For this reason, the designer typically substantially over-estimates the delay times. This tends to cause the execution time of the simulation to increase. Because of the difficulty in defining and executing the desired test cases, as described above, and because of the large number of test cases that are typically required, the logic simulation process can be the longest and most labor intensive part of the design process. Therefore, even a small increase in the efficiency of the logic simulation process, and in particular the test case definition and execution process, may significantly improve the efficiency of the overall design process.
The above limitations are magnified because the test designer must typically define and run a large number of test cases to achieve an adequate fault coverage.
The present invention overcomes many of the disadvantages of the prior art by providing an improved method and apparatus for synchronizing the execution of two or more test lists at desired synchronization points, while still allowing the test lists to execute in a non-deterministic manner between the synchronization points. In one illustrative embodiment, a test driver is provided to execute each test list, and a run controller is provided to monitor the execution of each test list by monitoring the state of each test driver. To synchronize the execution of two or more test lists, the run controller halts the execution of each test list as each test driver reaches a predetermined state. Once all of the test lists are halted, the test lists are synchronized. Once synchronized, selected test drivers can be restarted to continue relatively non-deterministic execution of the corresponding test lists.
It is contemplated that the test drivers may be Port Drivers, which are controlled by corresponding Port Driver test lists. A Port Driver is a test driver that drives a port of a multi-port circuit design. It is also contemplated that the execution of the Port Drivers may be coordinated by a run control Port Driver, which is controlled by a run control test list. The Port Driver test lists and the run controller test list are preferably generated using a program and spreadsheet interface, as disclosed in U.S. patent application Ser. No. 09/218,384, filed Dec. 22, 1998 entitled xe2x80x9cMethod And Apparatus For Efficiently Generating Test Input For A Logic Simulatorxe2x80x9d, which is incorporated herein by reference.
In one embodiment, the run control Port Driver initiates the execution of synchronized functions for each of the Port Drivers. The run control Port Driver then waits for an acknowledge signal from each Port Driver, indicating that each of the corresponding functions have been successfully completed. The acknowledge signal may be generated by a special instruction like a halt Jump instruction. Until an acknowledge signal is received from a particular Port Driver, that Port Driver continues execution in a relatively non-deterministic manner, at least relative to the other Port Drivers. The Port Drivers are synchronized when the run control Port Driver receives an acknowledge signal from each of the Port Drivers. Then the run control Port Driver may initiate a next set of functions to accomplish a next operation.
Like the Port Drivers, the run control Port Driver is preferably expressed using a behavioral description language. Accordingly, the run control test list may be initially loaded into a memory or the like incorporated into the behavioral description language of the run control Port Driver. In this configuration, the run control Port Driver may be simulated along with the Port Drivers and the circuit design, thereby reducing the need to interrupt the simulation kernel during simulation. Further, and because the run control Port Driver may monitor the state of each of the Port Drivers during simulation, it is not necessary to add delays to the Port Driver test lists, thereby reducing the required simulation time.
In an illustrative embodiment, the run control Port Driver is used to control a multi-port memory module wherein each port of the multi-port memory module is controlled by a corresponding Port Driver. The run control Port Driver includes a controller for synchronizing the execution of a first set of Port Drivers at desired synchronization points, while allowing the first set of Port Drivers to execute in a non-deterministic manner between the synchronization points.
It is contemplated that each of the acknowledge signals may be triggered by a synchronization command that is executed by each Port Driver. As indicated above, each of the Port Drivers is preferably controlled by a corresponding test list. At least some of the test lists may include one or more commands including a synchronizing command. Accordingly, the run control Port Driver may allow each of a first set of Port Drivers to execute the instructions in their test lists until a synchronization command is detected. The run control Port Driver can detect the synchronization command itself, the state of the corresponding Port Driver as a result of the execution of the synchronization command, or any other parameter that indicates that the synchronization command has been detected. The run control Port Driver may halt each of the Port Drivers as each synchronization command is detected. The Port Drivers arc synchronized when all Port Drivers have been halted. Once synchronized, the run control Port Driver may allow each of a second set of the Port Drivers to begin execution. The first set of Port Drivers and the second set of Port Drivers may or may not include one or more common Port Drivers.
It is contemplated that the run control Port Driver may execute a number of run control Port Driver instructions. A typical run control Port Driver instruction may include a function field and selected other fields including a source mask field and a control mask. The first set of Port Drivers are preferably selected by the source mask, and the second set of Port Drivers are preferably selected by the control mask.